-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[red-knot] Consolidate all gradual types into single Type variant #15386
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it! (haven't reviewed each and every change, but I guess it's more or less mechanical)
|
Brilliant idea! Is it possibly worth calling the variant and struct |
Also: all roads lead to Rome |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Brilliant idea! Is it possibly worth calling the variant and struct
Type::Gradual
andGradualType
rather thanType::Any
andAnyType
?Type::Any(AnyType::Unknown)
reads a bit strangely to me
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but I guess it's more or less mechanical
That is a good callout. I did try to make this a pure refactoring. For instance, there are a couple of places where we were doing something only for a Todo
, but not for Any
or Unknown
. Instead of inspecting and possibly changing those in this PR, I've left them as-is so that this PR does not combine a refactoring with a logic change.
todo @ Type::Todo(_) => return Ok(todo), | ||
todo @ Type::Any(AnyType::Todo(_)) => return Ok(todo), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e.g. here
* main: [red-knot] Move `UnionBuilder` tests to Markdown (#15374)
Co-authored-by: Alex Waygood <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is excellent!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes handling these in match statements so much nicer!
@@ -1085,9 +1082,16 @@ impl<'db> Type<'db> { | |||
pub(crate) fn is_same_gradual_form(self, other: Type<'db>) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side note on seeing this method, wondering why we need it, and going to look: I wonder if maybe we shouldn't allow Any/Unknown/Todo
to coexist in the same union/intersection, and instead should just define a hierarchy of preference, e.g. Todo
takes top priority, Any
second, and Unknown
third?
Definitely not something for this PR, just musing.
Co-authored-by: Carl Meyer <[email protected]> Co-authored-by: Alex Waygood <[email protected]>
Prompted by #15381 (comment):
The thought here is that most places want to treat
Any
,Unknown
, andTodo
identically. So this PR simplifies things by having a singleType::Any
variant, and moves the provenance part into a newAnyType
type. If you need to treat e.g.Todo
differently, you still can by pattern-matching into theAnyType
. But if you don't, you can just useType::Any(_)
.(This would also allow us to (more easily) distinguish "unknown via an unannotated value" from "unknown because of a typing error" should we want to do that in the future)